In order to gain access to applications or other resources via a computer or another user device, users are often required to authenticate themselves by entering authentication information. Such authentication information may include, for example, passwords that are generated by a security token carried by a user. These passwords may be, for example, one-time passwords that are generated using a time-synchronous or event-based algorithm.
In most existing token-based user authentication systems, a token belonging to a user U generates a one-time passcode for consumption by a single server S. In a symmetric-key-based scheme, the secret cryptographic keys from the token are shared with an authentication server. In most symmetric-key-based schemes, an adversary that compromises server S can impersonate user U by stealing the user's credentials from server S. Such an attack requires only transient server compromise; that is, the adversary need only learn the state of server S, and need not alter the operation of server S. In other attacks, the adversary can control the operation of server S over an extended period of time. Such an adversary can subvert the authentication process, impersonating user U even if the user's credentials are periodically refreshed, and even if authentication relies on public-key operations.
As noted, in a traditional symmetric-key cryptographic authentication setting, a server and a client share the same symmetric-key. By way of illustration, the RSA SecurID® user authentication token, commercially available from RSA Security Inc. of Bedford, Mass., U.S.A., can be used as an example. The SecurID® authentication server is replete with seed records, and the seed records are provisioned to the users by either sending the users a SecurID® hardware token or issuing SecurID® software token records.
Additionally, a token record provisioning process can be a difficult and costly process. In a SecurID® hardware token example, the token record provisioning process involves delivering a physical token to each user. In a SecurID® software token example, users are required to go through a series of steps, such as typing in a long uniform resource locator (URL) or 81 numeric numbers. Such steps may lead to unsatisfied customers and/or increasing numbers of support calls.
Accordingly, a need exists to provide a token (hardware or software) that, once provisioned to a user, can be shared by multiple service providers for authentication. Also, in contrast to single sign-on schemes that utilize an online central authentication service to perform authentication, it would be advantageous to provide a mechanism that allows service providers to perform their own authentications without knowing the symmetric-key that the client token holds.